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(54) Events as activities in process models of workflow management systems 



(57) The present invention relates to the area of 
workflow management systems (WFMS). WFMS exe- 
cute a multitude of process models consisting of a net- 
work of potentially distributed activities. The current 
invention is dedicated to the implementation of events 
within WFMS. The current invention teaches to imple- 
ment events like any other process activity. 
Thus events are implemented as event-activities, a spe- 
cial type of an activity within said WFMS. Such an 
event-activity can manage an event occurring internal or 
external to the WFMS. 

This approach allows to make all features available to 
common activities also accessible to event activities; 
examples are: input-container and/or output-container, 
control-connectors, data-connectors, notification-mech- 
anisms, predicates associated to control connectors 
forming transition conditions and many more. A control 
connector leaving an event activity, which optionally 
may be associated with a logical predicate as outgoing 
transition condition, allows the WFMS to automatically 
activate a target activity if said event activity terminated 
after the event has been signaled to said event activity 
and if the outgoing transition condition evaluates to true. 
Similar an incoming control connector, which optionally 
may be associated with a logical predicate as incoming 
transition condition, allows a WFMS to automatically 
activate an event activity if the process activity being the 
source of said incoming control connector terminated 
and if said incoming-transition -condition evaluates to 
true. 

This invention also teaches to extend the navigator of a 
WFMS by an event management system which inter- 



operates with the navigator to deliver above mentioned 
functionality. The event management system encom- 
passes the component of an event monitor administer- 
ing awaited events in a awaited event table and further 
administering signaled events in a posted event table. 
The event management system further encompasses 
the component of an event manager maintaining infor- 
mation on events allowing to verify correctness of an 
event. 
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Description 

1 Background of the Invention 

1.1 Held of the Invention 5 

The present invention relates to the field of compu- 
ter systems acting as workflow management systems 
(WFMS). 

10 

1.2 Description and Disadvantages of Prior Art 

A new area of technology with increasing impor- 
tance is the domain of Workflow-Management-Sys- 
tems (WFMS). WFMS support the modelling and is 
execution of business processes. Business processes 
control which piece of work of a network of pieces of 
work will be performed by whom and which resources 
are exploited for this work, i.e. a business process 
describes how an enterprise will achieve its business 20 
goals The individual pieces of work might be distributed 
across a multitude of different computer systems con- 
nected by some type of network. 

The process of designing, developing and manu- 
facturing a new product and the process of changing or 25 
adapting an existing product presents many challenges 
to product managers and engineers to bring the product 
to market for the least cost and within schedule while 
maintaining or even increasing product quality. Many 
companies are realizing that the conventional product 30 
design process is not satisfactory to meet these needs. 
They require early involvement of manufacturing engi- 
neering, cost engineering, logistic planning, procure- 
ment, manufacturing, service and support with the 
design effort. Furthermore, they require planning and 35 
control of product data through design, release, and 
manufacturing. 

The correct and efficient execution of business 
processes within a company, e. g. development or pro- 
duction processes, is of enormous importance for a 40 
company and has significant influence on company's 
overall success in the market place. Therefore, those 
processes have to be regarded similar as technology 
processes and have to be tested, optimized and moni- " 
tored. The management of such processes is usually 45 
performed and supported by a computer based process 
or workflow management system. 

In D. J. Spoon: "Project Management Environ- 
ment", IBM Technical Disclosure Bulletin, Vol. 32, No. 
9A, February 1990. pages 250 to 254, a process man- so 
agement environment is described including an operat- 
ing environment, data elements, and application 
functions and processes. 

In R. T Marshak; M IBM's FlowMark, Object-Ori- 
ented Workflow for Mission-Critical Applications". Work- 55 
group Computing Report (USA). Vol. 17, No. 5, 1994, 
page 3 to 13, the object character of IBM FlowMark as 
a client/server product built on a true object model that 



is targeted for mission-critical production process appli- 
cation development and deployment is described. 

In H. A. Inniss and J. H. Sheridan: "Workflow Man- 
agement Based on an Object-Oriented Paradigm", IBM 
Technical Disclosure Bulletin, Vol. 37. No. 3. March 
1994, page 185. other aspects of object-oriented mod- 
elling on customization and changes are described. 

In R Leymann and D. Roller: "Business Process 
Management with FlowMark", Digest of papers. Cat. 
No. 94CH3414-0, Spring COMPCON 94, 1994, pages 
230 to 234, the state-of-the-art computer process man- 
agement tool IBM FlowMark is described. The meta 
model of IBM FlowMark is presented as well as the 
implementation of IBM FlowMark. The possibilities of 
IBM FlowMark for modelling of business processes as 
well as their execution are discussed. The product IBM 
FlowMark is available for different computer platforms 
and documentation for IBM FlowMark is available in 
every IBM branch. 

In F. Leymann: "A meta model to support the mod- 
elling and execution of processes". Proceedings of the 
11th European Meeting on Cybernetics and System 
Research EMCR92. Vienna. Austria, April 21 to 24, 
1992. World Scientific 1992, pages 287 to 294. a meta 
model for controlling business processes is presented 
and discussed in detail. 

The "IBM FlowMark for OS/2", document number 
GH 19-8215-01. IBM Corporation. 1994. available in 
every IBM sales office, represents a typical modern, 
sophisticated, and powerful workflow management sys- 
tem. It supports the modelling of business processes as 
a network of activities; refer for instance to "Modeling 
Workflow", document number SH 19-8241, IBM Corpo- 
ration. 1996. This network of activities, the process 
model, is constructed as a directed, acyclic, weighted, 
colored graph. The nodes of the graph represent the 
activities or workitems which are performed. The 
edges of the graph, the control connectors, describe 
the potential sequence of execution of the activities. 
Definition of the process graph is via the IBM FlowMark 
Definition Language (FDL) or the built-in graphical edi- 
tor. The runtime component of the workflow manager 
interprets the process graph and distributes the execu- 
tion of activities to the right person at the right place, e. 
g. by assigning tasks to a work list according to the 
respective person/wherein said work list is stored as 
digital data within said workflow or process manage- 
ment computer system. 

In F Leymann and W. Altenhuber: "Managing busi- 
ness processes as an information resource", IBM Sys- 
tems Journal. VoL 32(2). 1994, the mathematical theory 
underlying the IBM FlowMark product is described. 

In D. Roller: "Verifikation von Workflows in IBM 
FlowMark". in J. Becker und G. Vossen (Hrsg.): 
"Geschaeftsprozessmodellierung und Workflows". 
International Thompson Publishing, 1995, the require- 
ment and possibility of the verification of workflows is 
described. Furthermore the feature of graphical anima- 
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tion for verification of the process logic is presented as 
it is implemented within the IBM FlowMark product. 

For implementing a computer based process man- 
agement system, firstly the business processes have to 
be analyzed and. as the result of this analysis, a proc- 
ess model has to be constructed as a network of activi- 
ties corresponding to the business process. In the IBM 
FlowMark product, the process models are not trans- 
formed into an executable. At run time, an instance of 
the process is created from the process model, called a 
process instance. This process instance is then inter- 
preted dynamically by the IBM FlowMark product. 

The concept of events as such on the other hand is 
known in the state of the art. Events for example play a 
role in database management systems. In database 
management systems event/trigger mechanism have 
been developed for consistency checking in databases 
as described for instance in A. M. Kotz, Triggermecha- 
nismen in Datenbanksystemen, Springer Verlag, Berlin 
1989. Also events play a central role in the notion of 
active databases. In workflow systems, the semantics 
of an event is quite imprecise as applied by A. W. 
Scheer, Wirtschaftsinformatik, Springer Verlag, Berlin 
1994 , where the event can be a termination condition of 
a previous activity or an external signal, such as the 
arrival of a letter or in general an incident occurring 
independent from an activity informing an activity asyn- 
chroneously on some type of change. According to this 
prior art approach an event is restricted to a quite lim- 
ited spectrum of possible sources. The relationship 
between the activity and the event may be such that the 
activity requires that the event is signaled to it otherwise 
the activity will not continue beyond a certain point. It is 
also possible that an event signaled to an activity will be 
perceived by that activity and depending on that percep- 
tion might modify the activity's ongoing processing. An 
event might result from anywhere within a computer 
system or even within networks of computer systems. 
Also the source of an event might be a hardware device, 
some software construct, a human interacting with a 
running computer system and so forth. 

1 .3 Objective of the Invention 

The invention is based on the objective to tightly 
integrate event mechanisms into workflow management 
systems 

2 Summary and Advantages of the Invention 

The objective of the invention is solved by claim 1 . 
WFMS. encompassing one or more computers, execute 
a multitude of process models consisting of a network of 
potentially distributed activities. For each activity infor- 
mation is defined within the WFMS which available pro- 
grams or processes do execute that activity. The current 
invention teaches to realize an event as an event activity 
encompassed by said process model said event activity 



being implemented as a special type of activity of said 
WFMS and said event activity managing an event which 
may occur internal or external to the WFMS. 

The technique proposed by the current invention 

5 achieves a new level of integration between WFMS and 
event technology. By exploiting and reusing the activity 
features very economic implementations for events are 
achieved. In addition conceptual gaps between the con- 
cepts of activities such as program or process and 

10 events are completely avoided. Moreover the approach 
allows to handle both, events occurring due to incidents 
within the WFMS as well as events having their source 
external to a WFMS. By conceptually handling an event 
as any other activity (for instance as a process activity). 

75 this concept allows to treat really any type of incident 
within a computer system as an event The current 
approach thus supports the broadest possible spectrum 
of possible events. By reusing to a certain extend the 
implementations of activities the overall system of a 

20 WFMS is not increased supporting compact and very 
responsive overall WFMS. , 

Additional advantages of the invention are accom- 
plished by claim 2. 

According this teaching said event activities are imple- 
25 mented by inheriting features and capabilities of the 
class of activities or of a sub-class thereof according to 
the principles of object-orientation. 

Such an approach allows for an elegant and very 
simple way of reusing capabilities already available 
30 within a system. 

Further additional advantages of the invention are 
accomplished by claim 3. 

Claim 3 teaches to implement event activities by associ- 
ating with it an event generator being a program irrtple- 

35 menting said event. According to the invention an event 
activity may have associated with it an input container 
and/or an output-container, the event activity may be the 
source and/or target of one or more control-connectors 
and the event activity may be the source and/or target of 

40 one or more data-connectors. Moreover it is taught by 
the current teaching, that the event activity may be 
associated with a notification mechanism allowing to 
freely define one or more actions to be performed by the 
WFMS if the event activity is not completed within a 

45 freely defined time period. 

This approach to events supports a complete trans- 
parency whether an event is of internal or external 
nature. Nevertheless the teaching allows to implement 
the event generator as a special purpose program 

50 implementing or handling really any type of event. Sep- 
arating the general aspects of an event, like signaling a 
dedicated consumer that the event happened, from the 
event generator avoids that these functions have to be 
realized over and over again. Instead these general 

55 aspects are implemented only once within the WFMS 
and are handled by the WFMS automatically. Of course 
all features which are available to normal activities are 
made available to event activities too thus easing the 
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implementation of events significantly. For instance 
input and output containers allow to provide an event 
generator with run-time information or to make results of 
an event available to consumers of an event. 

Further additional advantages of the invention are 5 
accomplished by claim 4. 

The invention suggest to introduce as one possible 
action which may be performed by the notification 
mechanism to automatically terminate the event if the 
event is not completed within a predefined time period. 10 

Such an approach allows to simulate a successful 
termination of an event activity if required. 

Further additional advantages of the invention are 
accomplished by claim 5 and 7. 

The current teaching allows that an event activity may 15 
be the source of one or more outgoing control connec- 
tors targeting at corresponding target activities. Such a 
process model will then make sure that the target activ- 
ities will be informed automatically by the WFMS on the 
event once the event is signaled to the waiting event 20 
activity an the event activity terminated. An outgoing 
control connector optionally may be associated with a 
logical predicate as outgoing transition condition mode- 
ling the fact that a target activity will be activated if said 
event activity terminated and said outgoing transition 25 
condition evaluates to true. The current invention fur- 
thermore teaches that one or more incoming control 
connectors of the corresponding source activities may 
targeting at an event activity. Such a process model will 
then allow the WFMS to automatically start the event 30 
activity once a source activity terminated its processing. 
An incoming control connector optionally may be asso- 
ciated with a logical predicate as incoming transition 
condition modeling the fact that the event activity will be 
started only by the WFMS if in addition said incoming 35 
transition condition evaluates to true. 

By this approach already the process graph allows 
to define via the control connectors which other activi- 
ties are to be started after an event or which process 
activities automatically start an event activity. This tech- 40 
nique establishes a standard approach to inform poten- 
tial consumers on an event and to start an event activity 
and event generators. Thus the event activities, the 
event generators or the potential consumers are 
relieved from performing extra activities for that pur- 45 
pose. Moreover event generators and event activities 
with interest in a certain event (either in creating or in 
waiting on an event) become significant easier to imple- 
ment. In addition above mentioned handling of the 
events is done automatically by the WFMS. The current so 
invention does not restrict these source and target activ- 
ities to a specific type of WFMS activities. Therefore the 
source and/or target activities might represent standard 
process activities, program activities or other types of 
activities but according to the current invention it would 55 
be also possible that one or both of them represent also 
event activities. In other words the current invention also 
supports chains or even complex graphs of event activ- 



ities. 

Further additional advantages of the invention are 
accomplished by claim 6. 

According claim 6 the WFMS is activating an event 
activity automatically when instantiating a process 
model if said event activity is not a target of a control 
connector. 

Thus no extra implementation is required to start a 
certain event generator. The WFMS takes care about 
these aspects automatically. 

Further additional advantages of the invention are 
accomplished by claim 8. 

According to claim 8 the WFMS registers said event 
activity as awaiting consumer of said event once said 
event activity is activated by the WFMS and wherein fur- 
ther said WFMS registers said event as posted event 
once the occurrence of said event is signaled by said 
event generator. 

Due to this teaching again the implementation of an 
event activity becomes much easier as the interest in a 
certain event is automatically detected by the WFMS by 
reading the process graph and the WFMS takes over 
responsibility to register an event activity's interest in 
that event. Moreover the implementation of event gener- 
ators is also significantly simplified as an event signaled 
by an event generator is registered automatically by the 
WFMS as posted event. 

Further additional advantages of the invention are 
accomplished by daim 9. 

This teaching suggests that a target activity is activated 
by said WFMS if as a first condition the event activity 
terminated and if as a second condition the outgoing 
transition condition evaluates to true independent at 
which point in time and in which sequence said first and 
said second condition are fulfilled. 

This behavior characteristic avoids that the sig- 
naled event is "consumed" if the transition condition is 
not fulfilled exactly at the point in time the event 
occurred. 

Further additional advantages of the invention are 
accomplished by claim 10. 

Claim 10 suggest to extend the WFMS navigator, per- 
forming navigation of operation trough the process 
graph of a process-model, by an event management 
system extending and inter-operating with said WFMS 
navigator. The event management system encom- 
passes the component of an event monitor administer- 
ing awaited events in at least one awaited event table 
and further administering signaled events in at least one 
posted event table. An event generator is signaling the 
occurrence of said event to said event monitor. 

This teaching extends the navigator with additional 
features to administer on one side all events which have 
been signaled to and to handle on the other side all 
potential consumers of an event and to associate both 
sides. Neither event generators nor activities do have to 
take care of these aspects. 

Further additional advantages of the invention are 
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accomplished by claim 11. 
* The teaching of claim 11 suggests an event manage- 
ment system encompassing the component of an event 
manager maintaining information on the events allowing 
to verify correctness of an event if said event is being 
signaled. 

Such an access further increases the reliability of 
the overall system. 

Further additional advantages of the invention are 
accomplished by claim 1 2. 

According to claim 11 the WFMS sends, if it detects that 
an event activity is awaiting for an event, an awaited 
event notification to said event monitor and if then said 
event monitor detects a matching posted event indica- 
tion in said posted, event table said event monitor indi- 
cates said event together with event data to said WFMS. 
If otherwise no matching posted event notification is 
detected said event monitor stores an awaited event 
indication in said awaited event table. Also according to 
claim 12 said event generator indicates the occurrence 
of an event by a posted event indication to said event 
monitor which verifies ssiid posted event indication by 
consulting said event manager and then stores said 
posted event indication in said posted event table and if 
then said event monitor detects a matching awaiting 
event indication in said awaiting event table it indicates 
this together with event data to the WFMS. 

The approach of claim 12 improves responsiveness 
of the WFMS by at once checking whenever either a 
new event arrived or a new consumer is waiting for an 
event whether a matching event-consumer pair can be 
detected allowing the WFMS to inform that consumer 
on the signaled event. 

Further additional advantages of the invention are 
accomplished by claim 13. 

Claim 13 teaches that an event generator is informed, if 
an awaited event indication is stored in said awaited 
event table, on this awaited event indication. 

This technique informs an event generator auto- 
matically on consumers awaiting some kind of event. 
Such an approach avoids that an event generator peri- 
odically has to check for possible event consumers and 
thus avoids performance degradations. 

3 Brief Description of the Drawings 



Figure 1 is a diagram-reflecting multiple aspects of 

the embedding of events as a new type of 

activity within a WFMS 
Figure 2 is a visualization of the two fundamental 
. embedding modes of events as event 

activities within a process model 
Figure 3 reflects the major components of the 

Event Management System 
Figure 4 depicts the structure of the "awaited event 

table" and the "posted event table" 
Figures is a visualization of the FDL registration 

definitions required to model an event 
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is a visualization of the FDL definition of 
an event 

is a visualization of the FDL definition for 
exploiting the notification mechanism for, 
an event 

is a simple sample process model reflect- 
ing the usage of event activities 
reflects the most important data struc- 
tures of the example of Figure 8 
is a visualization of an event modeled as 
an event activity within the process model 
of the example of Figure 8 
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4 Description of the Preferred Embodiment 

The current invention is illustrated based on IBM's 
FlowMark workflow management system. Of course 
any other WFMS could be used instead. Furthermore 
the current teaching applies also to any dther type of 
system which offers WFMS functionalities not as a sep- 
arate WFMS but within some other type of system. 

4.1 Introduction 

The following is a short outline on the basic con- 
cepts of a workflow management system based on 
IBM's FlowMark WFMS: 

From an enterprise point of view the management 
of business processes is becoming increasingly impor- 
tant: business processes or process for short control 
which piece of work will be performed by whom and 
which resources are exploited for this work, i.e a busi- 
ness process describes how an enterprise will achieve 
its business goals. A WFMS ma^suppiort both, the 
modeling of business processes and their execution. 

Modeling of a business process as a syntactical 
unit in a way that is directly supported by a software sys- 
tem is extremely desirable. Moreover, the software sys- 
tem can also work as an interpreter basically getting as 
input such a model: The model, called a process 
model or workflow model, can then be instantiated 
and the individual sequence of work steps depending 
on the context of the instantiation of 'the' model can 'be 
determined: Such a model of a business process can be 
perceived as a template for a class of similar processes 
performed within an enterprise; it is a schema describ- 
ing all possible execution variants of a particular kind of 
business process. An instance of such a model and its 
interpretation represents an individual process, i.e. a 
concrete, context dependent execution of a variant pre- - 
scribed by the model. A WFMSs facilitates the manage- 
ment of business processes. It provides a means to 
describe models of business processes (build time) and 
it drives business processes based on an associated 
model (run time) The meta model of IBM's WFMS 
FlowMark. i.e. the syntactical elements provided for 
describing business process models, and the meaning 
and interpretation of these syntactical elements, is 
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described next- 

A process model ts a complete representation of a 
process, comprising a process diagram and the settings 
that define the logic behind the components of the dia- 
gram. Using ( various services provided by FlowMark 
these btildtime definitions the process models are then 
converted into process templates for use by FlowMark 
at runtime. Important components of a FlowMark proc- 
ess model are: 

■ Processes 

■ Activities 

■ Blocks\ 

■ Control Rows 

■ Connectors 

■ Data Containers 

■ Data Structures 

■ Conditions 

■ Programs 

■ Staff 5 ; 

Not all of these elements will be described below. 

On this background a process, modeled by a proc- 
ess model within FlowMark, is a sequence of activities 
that must be completed to accomplish a task. The proc- 
ess is the top-level element of a FlowMark workflow 
model. In a FlowMark process, it can be defined: 

How work is to progress from one activity to the 
next I 

Which persons are to perform activities arid what 
programs they are to use 

Whether any other processes, called subproc- 
esses, are nested in the process 

Of course multiple instances of a FlowMark process can 
run in parallel. 

Activities are the fundamental elements of the 
meta model. An activity represents a business action 
that is from a certain perspective a semantical entity of 
its own. With the model of the business process it might 
have a fine-structure that is then represented in turn via 
a model, or the details of it are not of interest at all from 
a business process modeling point of view. Refinement 
of activities .via process models allows for both, mode- 
ling business processes bottom-up and top-down. 
Activities being a step within a process represents a 
piece of work that the assigned person can complete by 
starting a program or another process. In a process 
model, the following information is associated with each 
activity: 

♦ What conditions must be met before the activity can 
start 

• Whether the activity must be started manually by a 
user or can start automatically 

What condition indicates that the activity is com- 
plete 



Whether control can exit from the activity automati- 
cally or the activity must first be confirmed as com- 
plete by a user 

How much time is allowed for completion of the 
5 activity 

Who is responsible for completing the activity 
Which program or process is used to complete the 
activity 

What data is required as input to the activity and as 
10 output from it 

A FlowMark process model consists of the following 
types of activities: 

rs Program activity: Has a program assigned to per- 
form it The program is invoked when the activity is 
started. In a fully automated workflow, the program 
performs the activity without human intervention. 
Otherwise, the user must start the activity by select- 

20 ing it from a runtime work list. Output from the pro- 
gram can be used in the exit condition for the 
program activity and for the transition conditions to 
other activities. 

Process activity: Has a (sub-)process assigned to 
25 perform it The process is invoked when the activity 
is started. A process activity represents a way to 
reuse a set of activities that are common to different 
processes. Output from the process, can be used in 
the exit condition for the process activity and for the 
3d transition conditions to other activities. 

The flow of control, i.e. the control flow through a 
running process determines the sequence in which 
activities are executed. The FlowMark workflow man- 

35 ager navigates a path through the process that is deter- 
mined by the evaluation to true of start conditions, exit 
conditions, and transition conditions. 

The results that are in general produced by the 
work represented by an activity is put into an output 

40 container, which is associated with each activity. Since 
an activity will in general require to access output con- 
tainers of other activities, each activity is associated in 
addition with an input container too At run time, the 
actual values for the formal parameters building the 

45 input container of an activity represent the actual con- 
text of an instance of the activity. Each data container is 
defined by a data structure. A data structure is an 
ordered list of variables, called members, that have a 
name and a data type. Data connectors represent the 

so transfer of data from output containers to input contain- 
ers. When a data connector joins an output container 
with an input container, and the data structures of the 
two containers match exactly the FlowMark workflow 
manager maps the data automatically. 

55 Connectors link activities in a process model. 
Using connectors, one defines the sequence of activi- 
ties and the transmission of data between activities. 
Since activities might not be executed arbitrarily they 
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are bound together via control connectors. A control 
connector might be perceived as a directed edge 
between two activities; the activity at the connector's 
end point cannot start before the activity at the start 
point of the connector has finished (successfully). Con- 
trol connectors model thus the potential flow of control 
within a business process model. Default connectors 
specify where control should flow when the transition 
condition of no other control connector leaving an activ- 
ity evaluates to true. Default connectors enable the 
workflow model to cope with exceptional events. Data 
connector specify the flow of data in a workflow model. 
A data connector originates from an activity or a block, 
and has an activity or a block as its target. One can 
specify that output data is to go to one target or to mul- 
tiple targets. A target can have more than one incoming 
data connector. 

Conditions are the means by which it is possible to 
specify the flow of control in a process. In FlowMark 
process models logical expressions can be defined that 
are evaluated by FlowMark at runtime to determine 
when an activity may start, end, and pass control to the 
next activity. Start conditions are conditions that deter- 
mine when an activity with incoming control connectors 
can start: The start condition may specify that all incom- 
ing control connectors must evaluate to true, or it may 
specify that at least one of them must evaluate to true. 
Whatever the start condition, all incoming connectors 
must be evaluated before the activity can start. If an 
activity has no incoming control connectors, it becomes 
ready when the process or block containing it starts. In 
addition, a Boolean expression called transition condi- 
tion is associated with each control connector. Parame- 
ters from output containers of activities having already 
produced their results are followed as parameters refer- 
enced in transition conditions. When at run time an 
activity terminates successfully all control connectors 
leaving this activity are determined and the truth value 
of the associated transition conditions is computed 
based on the actual values of their parameters. Only the 
end points of control connectors the transition condi- 
tions of which evaluated to TRUE are considered as 
activities that might be executed based on the actual 
context of the business process. Transition conditions 
model thus the context dependent actual flow of control 
within a business process (i.e. an instance of a model). 
Business processes encompass long running activities 
in general; such an activity need to be allowed to 
become interrupted. Thus, termination of an activity 
does not necessarily indicate that the associated task 
has been finished successfully. In order to allow the 
measurement of successful In ess of the work performed 
by an activity a Boolean expression called exit condi- 
tion is associated with each activity. Exactly the activi- 
ties the exit condition of which evaluated to true in the 
actual context are treated as successfully terminated. 
For determination of the actual control flow precisely the 
successfully terminated activities are considered. Thus 



the logical expression of an exit condition, if specified, 
must evaluate to true for control to pass from an activity 
or block. 

Beside describing the potential flow of control and 

5 data between activities a business process model also 
encompasses the description of the flow of the activities 
itself between "resources" actually performing the 
pieces of work represented by each activity. A resource 
may be specified as a particular program, person, a 

w role, or an organizational unit. At run time tasks are 
resolved into requests to particular persons to perform 
particular activities resulting in workitems for that per- 
son. Staff assignments are the means to distribute 
activities to the right people in the sequence prescribed 

is by the control flow aspect of a business process model. 
Each activity in a process is assigned to one or more 
staff members defined in the FlowMark database. 
Whether an activity is started manually by the user or 
automatically by the FlowMark workflow manager, and 

20 whether it requires user interaction to complete or com- 
pletes automatically, a staff member must be assigned 
to it. FlowMark staff definition entails more than identify- 
ing people at your enterprise to the FlowMark database, 
For each person defined, you can specify a level, an 

25 organization, and multiple roles. These attributes can 
be used at run time to dynamically assign activities to 
people with suitable attributes. 

In the FlowMark workflow manager, program 
means a computer-based application program that sup- 

30 ports the work to be done in an activity. Program activi- 
ties reference executable programs using the logical 
names associated with the programs in FlowMark pro- 
gram registrations. The program registration can con- 
tain run-time parameters for the executable program. 

35 FlowMark consists, at the coarsest level, of a build 
time component and a run time component. The build 
time component supports the modeling of business 
processes according to the meta model described 
above and the run time component supports the corre- 

40 sponding semantics. Both components are imple- 
mented in a client/server structure. The client delivers 
the interaction with the user via an object-oriented 
graphical interface, invokes local tools, and provides 
animation. The server maintains the database for proc- 

45 ess instances, navigates through the process graph, 
and assigns the activities to the proper resources. 

Process definition includes modeling of activities, 
control connectors between the activities, input/output 
container, arid data connectors. A process is repre- 

so sented as a directed acyclic graph with the activities as 
nodes and the control/data connectors as the edges of 
the graph. The graph is manipulated via a built-in, event- 
driven. CUA compliant graphic editor. The data contain- 
ers are specified as named data structures. These data 

55 structures themselves are specified via the DataStruc- 
tureDefinition facility. FlowMark distinguishes three 
main types of activities: program activities, process 
activities, and blocks. Program activities are imple- 
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mented through programs. The programs are registered 
via the Program Definition facility. Blocks contain the 
same constructs as processes, such as activities, con- 
trol connectors etc. They are however not named and 
have their own exit condition. If the exit condition is not 
met, the block is started again. The block thus imple- 
ments a Do Until construct. Process activities are imple- 
mented as processes. These subprocesses are defined 
separately as regular, named processes with all its 
usual properties. Process activities offer great flexibility 
for process definition. It not only allows to construct a 
process through permanent refinement of activities into 
program and process activities (top-down), but also to 
build a process out of a set of existing processes (bot- 
tom-up). In particular, process activities help to organize 
the modeling work if several process modeler are work- 
ing together. It allows the team members to work inde- 
pendently on different activities. Program and process 
activities can be associated with a time limit. The time 
limit specif ies how long the activity may take. If the time 
is exceeded, a designated person is notified. If this per- 
son does not react within another time limit, the process 
administrator is notified. It not only helps to recognize 
critical situation but also to detect process deficiencies 
as all notifications are recorded in an audit trail. 

All data structures used as templates for the con- 
tainers of activities and processes are defined via the 
Data Structure Definition Facility. Data Structures are 
names and are defined in terms of elementary data 
types, such as float, integer, or string and references to 
existing data structures. Managing data structures as 
separate entities has the advantage that all interlaces of 
activities and their implementations are managed con- 
sistently in one place (similar to header files in program- 
ming languages). 

All programs which implement program activities 
are defined via the Program Registration Facility. Regis- 
tered for each program is the name of the program, its 
location, and the invocation string. The invocation string 
consists of the program name and the command string 
passed to the program. 

Before process instances can be created, the proc- 
ess model must be translated to ensure the correctness 
and completeness of the process model. The translated 
version of the model is used as a template when a proc- 
ess instance is created. This allows to make changes to 
the process model without affecting executing process 
instances. A process instance is started either via the 
graphical interface of via the callable process applica- 
tion programming interface. When a process is started, 
the start activities are located, the proper people are 
determined, and the activities are posted onto the work 
list of the selected people. If a user selects the activity, 
the activity is executed and removed from the work list 
of any other user to whom the activity has been posted. 
After an activity has executed, its exit condition is evalu- 
ated. If not met, the activity is rescheduled for execution, 
otherwise all outgoing control connectors and the asso- 



ciated transition conditions are evaluated. A control con- 
nector is selected, if the condition evaluates to TRUE. 
The target activities of the selected control connectors 
are then evaluated. If their start conditions are true, they 
s are posted to the work list of selected people. A process 
is considered terminated, if all end activities have com- 
pleted. To make sure that all end activities finish, a 
death path analysis is performed, ft removes all edges 
in the process graph which can never be reached due to 
w failing transition conditions. All information about the 
current state of a process is stored in the database 
maintained by the server. This allows for forward recov- 
ery in the case of crashes. 

is 4.2 Concepts 

To achieve an integration of events within WFMS 
which is as seamless as possible the basic approach of 
the current invention is to let events appear as a certain 
20 type of activity in terms of a WFMS. More precisely this 
patent application teaches how events can be treated 
and implemented as a subclass of the class of activities 
inheriting (in the sense of object orientation) the com- 
mon properties of activities. 
25 FlowMark activities are either program activities or 
process activities. Program activities are implemented 
via a program which is invoked when the activity is exe- 
cuted; process activities are implemented via a sub- 
process, which is started when the activity is executed. 
30 The sequence of execution of the various activities of a 
process model are described via the control connectors. 
Activities which are only the target of control connectors 
are called end activities, activities which are only the 
source of control connectors, are called start activities. 
35 Which control connector is being followed is defined via 
predicates. Each activity is associated with an input 
container and an output container. The input container 
contains the data required by the implementation of the 
activity to perform the correct processing; the output 
40 container is filled by the activity with information to con- 
trol the process and data to be used by subsequent 
activities. Data connectors are used to describe what 
data from which output container should be used for the 
data in the input container of activities subsequent 
45 according to the process graph. Activities are associ- 
ated with a notification mechanism, which allows to 
specify that an action, such as sending a notification 
message to a designated user, is performed, if the activ- 
ity has not been worked on for a defined period of time. 
so The concept of events is the mechanism which 
allows the process modeler to specify that the process 
should wait at this point until the specified event hap- 
pens. This event could be that a certain date occurs, or 
that a letter should be received from a customer. The 
55 occurrence of the event may be signalled from an activ- 
ity within another process or from any other program, 
such as an agent in Lotus Notes. In general an event is 
an incident occurring independent from an activity 
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informing an activity asynchroneously on some type of 
change. This change might be internal or external to the 
WFMS. The relationship between the activity and the 
event may be such that the activity requires that the 
event is signaled to it otherwise the activity will not con- 
tinue beyond a certain point. It is also possible that an 
event signaled to an activity will be perceived by that 
activity and depending on that perception might modify 
the activity's ongoing processing. An event might result 
from anywhere within a computer system or even within 
networks of computer systems. Also the source of an 
event might be a hardware device, some software con- 
struct, . a human interacting with a running computer 
system and so forth. 

The patent application shows how events can be 
modelled within a WFMS as a special kind of activity, 
the event activity. It specializes in the sense of object 
orient technology the general activity and inherits all 
properties of the general activity Therefore, an event 
(activity) may be associated with an input and output 
container and may be the source and the target of con- 
trol connectors as well the source and target of data 
connectors; i.e. all constructs and techniques available 
to general activities are available to event activities 
according to the current teaching too. Events may have 
a start condition and may be associated with a notifica- 
tion. An event activity is associated with an event similar 
to process activities which are associated with pro- 
grams. 

Thus an "event" describes a conceptual and 
semantical entity, while the "event activity" is the model 
of that event modelled with the features of a WFMS. The 
programs associated with the event are called event 
generators and represent the means and constructs for 
creating or handling a particular event. 

Figure 1 reflects multiple aspects of the embedding 
of events as a new type of activity within a WFMS 
according the teaching of the current invention. The new 
type of activity, the event activity 100, is realized as a 
sub-class of the class of activities 101. Via relationship 
and inheritance mechanisms the full spectrum of fea- 
tures and capabilities available to activities is made 
available to event activities too. Thus event activities 
may exploit the available notification features 102, the 
full spectrum of data structure features 103 or the vari- 
ous connector features like control connectors 1 04 and 
data connectors 105. Also shown by Figure 1 is the rela- 
tionship of the model of an event 1 06 with one or more 
event activities 100 and the relationship of a program 
107, an event generator implementing or handling an 
event, with one or morie event activities 106. 

The control connectors originating from an event 
activity are treated as usual, i.e. their truth value of pred- 
icates potentially associated with those control connec- 
tors contribute to starting conditions of activities. Also, 
there may be more than one control connector emanat- 
ing from a particular event activity. The usual navigation 
semantics will evaluate the transition conditions of the 



associated control connectors immediately; thus, 
events will not be physically consumed (in the sense 
that an event can be dedicated to a particular control 
connector leaving the event activity node) but are avail- 

5 able for all originating branches. If exclusive validity of 
an event for a particular branch is required it must be 
expressed via suitable transition conditions. 

An event activity can also be a target of a control 
connector. This means that an instance of the corre- 

io sponding event is created (but hot signalled) rf the tran- 
sition condition of the control connector pointing to the 
event activity is fulfilled. Using control connectors point- 
ing to event activities can be used to explicitly activate 
events within particular process instance contexts. If an 

15 event is activated, the activity waiting for that event has 
registered for that event and all other activities being 
according to the FlowMark process model the target of 
a control connector originating at the event activity are 
then potential consumers of that event. 

20 Figure 2 illustrates how two different cases for 
embedding events as event activities within a process 
model can be differentiated, exactly as is the case with 
regular activities. On the left side (1), the activity A 201 
must have terminated successfully and the transition 

25 condition 202 between A and the event activity E 203 
must have been evaluated to 'true' before the event 
node E is sensitive for recognition. Thus, if an instance 
of E is signalled, this is not recognized before the transi- 
tion condition between A and E is met Once E is sensi : 

30 tive for recognition (i.e. activated) the activity B 204 has 
registered for the appropriate instance of E automati- 
cally through the modelled process graph. Event activi- 
ties for this first type may be used for instance if the 
cause of an event is located at least partially within a 

35 process model itself. 

On the right side (2), the transition condition 210 
between the event activity E 21 1 and the activity B 212 
will be evaluated as soon as the event E is recognized 
even if the activity A 213 has not been terminated. Con- 

40 sequeritly, E is activated when the process model is 
instantiated, i.e. B has registered for E right away. 

When activating an event activity its associated 
input container is materialized. The usual rules for data 
connectors do apply. The output container of an event 

45 activity is created by the event generator associated 
with the subject event (see below). 

4.3 Components of Event Management Services 

so The navigator is the piece of the workflow manage- 
ment system that performs the navigation through the 
process graph. For handling events this navigator is 
extended by an Event Management System encom- 
passing event management services which are inter- 

55 operating with the navigator. These event management 
services are logically different components which may 
or may not coincide with physical means implementing 
those functions. Figure 3 reflects the major components 
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of the event management services. The event monitor 
301 is responsible for keeping track of awaited and 
posted events. The event generators 302 are pro- 
grams that signal the occurrence of an event to the 
event monitor. The event manager 303 keeps the irrfor- 5 
mation about events. 

When the navigator 304 detects that an event is 
expected by particular activities of a process instance 
this is indicated to the event monitor. If the event monitor 
finds a matching entry in its posted event table 305 it 10 
indicates so immediately to the navigator and passes 
the associated data with its response. Otherwise, the 
event monitor reflects the awaited event by an appropri- 
ate entry in the awaited event table 306. 

An event generator signals the occurrence of an is 
event to the event monitor. The event monitor verifies 
the correctness of the event by consulting the event 
manager. If the event monitor detects a corresponding 
entry in the "awaited event table" this is indicated to the 
navigator. Otherwise, the event is inserted into the 20 
"posted event table". 

The tables "awaited event table" and "posted event 
table" are first of all logical objects. Physically they actu- 
ally may be implemented as different or as common 
tables. 25 

4.4 Tracking of Events 

It can be perceived that events and their event indi- 
cations within the posted and awaited event table are 30 
managed in tabular formats as depicted in the Figure 4. 
ProcID refers to the identifier of the process instance in 
which the event is waited for. The EventID identifies a 
particular event in this process instance (as node in the 
process model). The EventName refers to the category 35 
of the event and the InputContainer column contains the 
actual values of the fields in the associated input con- 
tainer of the event. 

It has to be noted that the EventID is needed 
because events having an incoming control connectors 40 
are only "activated" if the transition conditions of the 
incoming control connectors are met and the start con- 
dition is true. An event which is not activated is not 
reflected in the "awaited event table". Events with no 
incoming control connector are activated at process 45 
instantiation time. 

The posted events table is used to store generated 
events which are currently not waited for as no potential 
consumer has registered for it. Such an event is kept in 
this table until somebody registers for it (potentially, an so 
event may be kept "forever") or if it is removed via gar- 
bage collection. The ProcID column in this table repre- 
sents an optional value for tupels of this table and can 
be used for specifying particular process instances 
which might consume the event instance. 55 



4.5 Cancelling Events 

An awaited event can be cancelled in two ways : (1) 
as the result of a notification action, such as FORCE 
TERMINATE or (2) through an explicit request from the 
user via functions supplied by the event monitor. When 
an awaited event is cancelled, it is removed from the 
waited event table and the event monitor signals the 
completion of the event to the navigator. Any outgoing 
control connector is treated as if the event had hap- 
pened normally. 

4.6 Event Identification 

The association of an incoming event, such as 
receiving a letter, with the waited for event is performed 
by comparing the identification fields provided by the 
event generator with the fields defined in the input con- 
tainer plus the fields defined in the input container by 
default, which is the process instance identification and 
the event identification. No problem arises H the event 
generator itself provides the process instance identifica- 
tion and the event identification. If the process instance 
identifier is not supplied, the fields in the input container 
are compared with the appropriate fields delivered by 
the event generator (signature matching). 

4.7 Event Generator 

The event generator signals that an event has hap- 
pened by calling the event monitor via the event monitor 
interface- The event generator can determine when the 
event should be signalled. This can be done by periodi- 
cally querying the event monitor to determine if a new 
entry for the event generator has been entered in the 
awaited event table. An event generator may also regis- 
ter itself with the event monitor and request that each 
new registration of an awaited event is signalled to the 
event generator. 

The supplied date/time event generator for example has 
a data structure with a date field and a time field. These 
fields can either be filled by a data connector leading to 
that event or values set as defaults by the process mod- 
eler. The time/date event generator has registered with 
the event monitor that it should be called when a new 
event is registered. 

4.8 Event Monitor Programming interface 

The event monitor provides an application program- 
ming interface to allow applications to request event 
monitor functions. The set of functions include requests, 
such as querying the posted event table, removing 
entries from the posted event table, querying the 
awaited event table, removing entries from the awaited 
event table, and inserting entries into the posted event 
table. 
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4.9 Event Registration 

An event activity is always associated with an 
event. The event has a number of properties: the name 
of the program implementing the event generator, the 5 
name of the event, and an indicator whether the event 
generator should be started as part of starting the Row- 
Mark server. An important property is the operation 
mode of the event generator, which defines whether the 
event generator should be called every time a new event io 
is added to the awaited events table or not. If specified, 
this allows the event generator to keep internal tables 
for efficient processing and does not require periodically 
reading the awaited event table. 

15 

4.10 Event Notification 

Events also inherit (in the sense of object oriented 
technology) the notion of notification from the activity. 
Notification allows to define actions which are taken 20 
whenever the defined time for completion is exceeded. 
Extensions to the notification mechanism allow to spec- 
ify other actions than just sending a notification mes- 
sage to a designated person. These extensions include 
actions like terminating the activity. 25 

4.11 Process Model Additions 

The support of events requires minor additions to 
the FlowMark Definition Language (FDL). 30 
Events are registered (in the sense of the FDL) via the 
EVENT section. It is similar to the PROGRAM section 
which supports the registration of programs. Figure 5 
shows the FDL registration of the event "Wait for Cus- 
tomer Response". The associated generator program 35 
is "MaiiCheckProgram". The program is started as a 
result of starting the FlowMark server, specified due to 
AUTOSTART, and is notified whenever an event is 
entered into the awaited event table, specified due to 
NOTIFY. 40 

Event activities of a process model are defined via 
the EVENTACTIVITY section. This mechanism is 
almost identical to the PROGRAM_ACTIVITY keyword. 
The event type is specified via the EVENT_TYPE key- 
word followed by a string containing the event type. A 45 
particular event type may be specified only once within 
a process model. Figure 6 shows how an event is 
defined. The data structure "Event Identification" 
defines the structure of the input container associated 
with the event. It contains ail relevant information to so 
identify the event. This information is used by the event 
monitor to compare it with the information supplied by 
the event generator. The data structure "Response 
Information" defines the structure of the output con- 
tainer associated with the event. The data is supplied by 55 
the event generator. 

Notification of events is enhanced to provide the 
capability to force terminate the event, that means that 



the event is considered complete even if ho event has 
been signalled during the specified time. Figure 7 
shows how it could be specified that it should only be 
waited 14 days for the customer letter to arrive. 

4.12 Advantages 

The proposed method of treating events as activi- 
ties has, besides the effect of offering a seamless exten- 
sion and transition of workflow activities, a number of 
advantages over other possible approaches that treat 
events differently. 

1 Events follow the same metaphor as activities. 

1.1 Control Connectors activate an event. 
The predicates on the incoming control con- 
nectors as well as the outgoing control connec- 
tors allow to specify which event should be 
waited for and which activity should be exe- 
cuted as the result of the happening of an 
event. Events without an incoming control con- 
nector are immediately activated as are start 
activities. 

1 .2 Data Connectors allow to fill the input con- 
tainer with the event relevant data. No new 
mechanism is required to identify the instance 
of the event for which it should be waited for. 

1.3 Input Containers identify to activities what 
the context is in which they are calleid. The 
same is true for event activities as the contents 
of the input container identifies the particular 
characteristics of the event which is waited for. 

1.4 Output Containers contains the process 
relevant information generated by an activity. 
For event activities, the event signaller provides 
this information, for example, the identification 
of the letter which has been received, which is 
process relevant information. 

1 .5 Notification allows to specify what should 
happen if an activity has not been completed 
within a defined time limit. The same behavior 
is true for event activities, where this mecha- 
nism is used in the same way. 

1.6 Events can be handled within Spheres of 
Joint Compensation the same way as activi- 
ties. 

2 Events can be graphically managed the same 
way as are activities. 

3 Events can be described in the FlowMark Defini- 
tion Language with similar constructs as program 
activities. 

4 Treating events as activities allows to re-use the 
code used for processing process models, such as 
navigating the graph. Re-use of this code Provides 
a number of advantages, such as 
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4.1 Less errors 

4.2 Easier testing 

5 Events can be monitored the same way as other 
activities via the process instance-monitor. s 

All in all these advantages help to compactify the 
overall system, contribute to minimize the implementa- 
tion effort and thus increase the responsiveness of the 
WFMS. w 

4.13 Example 

A simple process model in Figure 8 illustrates the 
usage of events. In a claims processing application of 75 
this example additional info is required from a customer 
801 . The process warts until information is received 802. 
If the customer responded via fax, the fax is processed 
with a certain piece of software 803. otherwise another 
piece of software is used 804. 2 o 

Figure 9 shows the definitions of the most important 
data structures being of importance within the example 
of Figure 8. Finally Figure 10 is a visualization of the 
event modeled as an event activity "Wait for 
Response" in lines 5, to 9 within the process model of 25 
the example of Figure 8. Figure 10 further demonstrates 
in lines 14 to 21 usage of control connectors and in line 
21 to 31 usage of data connectors for the event activity 

5 Acronyms 30 

DB Database 

FDL FlowMark Definition Language 
WFMS Workflow Management System 

35 

Claims 

1. A computer system encompassing one or more 
computers storing an implementation of a process- 
model for a workflow-process-environment said 40 
process-model managed and executed by said 
computer system, said computer system being 
characterized by 

at least one event-activity encompassed by 45 
said process-model said event-activity being 
implemented as an activity of said workflow- 
process-environment 
and 

50 

said event-activity managing an event occur- 
ring internal or external to the workflow-proc- 
ess-environment. 

2. A computer system according to claim 1 55 
wherein said event-activity being implemented by 
inheriting features and capabilities of the class of 
activities or of a sub-class thereof according to the 



principles of object-orientation. 

3. A computer system according to any of above 
claims 

wherein said event-activity is associated with 
an event, and 

wherein said event-activity may have associ- 
ated with it an input-container and/or an output-con- 
tainer, and 

wherein said event-activity may be the 
source and/or target of one or more control-connec- 
tors, and 

wherein said event-activity may be the 
source and/or target of one or more data-connec- 
tors, and 

wherein said event-activity may be associ- 
ated with a notification-mechanism allowing to 
freely define at least one action to be performed by 
the workflow-process-environment if said event- 
activity is not completed within a freely defined time 
period. 

4. A computer system according to claim 3 

wherein said event is implemented by an 
event-generator 

5. A computer system according to claim 4 

wherein said event-generator is imple- 
mented as a program. 

6. A computer system according to anyone of claim 3 
to 5 

wherein said action automatically terminate 
said event-activity. 

7. A computer system according to any of above 
claims 

wherein said process-model encompassing 
at least one outgoing-control-connector said event- 
activity being the source and a target-activity being 
the target of said outgoing-control-connector, and 

wherein said outgoing-control-connector 
optionally may be associated with a logical predi- 
cate as outgoing-transition-condition, and 

wherein said workflow-process-environment 
activates said target-activity if said event is signaled 
to said waiting event-activity and finally said 
eventactivity terminated and if said outgoing-transi- 
tion-condition evaluates to true. 

8. A computer system according to any of above 
claims 

wherein said workflow-process-environment 
is activating said event-activity automatically when 
instantiating said process-model if said event-activ- 
ity is no target of a control-connector. 

9. A computer system according to claim 1 to 7 
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wherein said process-model encompassing 
at least one incoming-control-connector said event- 
activity being the target and a source-activity being 
the source of said incoming-control-connector, and 

wherein said incoming-control-connector 5 
optionally may be associated with a logical predi- 
cate as incoming-transition-condrtion, and 

wherein said workf low-process-environment 
activates said event-activity if said source-activity 
terminated and said incoming-transition-condition 70 
evaluates to true. 

10. A computer system according to claim 7 to 9 

wherein said workflow-process-envtronment 
registers said event-activity as awaiting consumer 15 
of said event once said event-activity is activated by 
said workf tow-process-environment, and 

wherein further said workflow-process-envi- 
ronment registers said event as posted-event once 
the occurrence of said event is signaled by said 20 
event-generator. 



1 1 . A computer system according to claim 7 to 1 0 

wherein said target-activity is activated by 
said workflow-process-environment if as a first con- 
dition said event-activity terminated and if as a sec- 
ond condition said outgoing-transition-condition 
evaluates to true independent at which point in time 
and in which sequence said first and said second 
condition are fulfilled. 

12. A computer system according to claim 10 encom- 
passing a workflow-navigator performing navigation 
of operation trough the process-graph of said proc- 
ess-model and said computer system being further 
characterized by 

an event-management-system extending and 
inter-operating with said workflow-navigator, 
and 



wherein said workflow-navigator sends, if it 
detects that said event-activity is awaiting for said 
event, an awaited-event-notification to said event- 
monitor and if then said event-monitor detects a 
matching posted-event-indication in said posted- 
event- table said event-monitor indicates said event 
together with event-data to said workflow-navigator 
or if otherwise no matching posted-event-notifica- 
tion is detected said event-monitor stores an 
awaited-event-indication in said awarted-event- 
table, and 

wherein said event-generator indicates the 
occurrence of said event by a posted-event-indica- 
tion to said event-monitor which verifies said 
posted-event-indication by consulting said event- 
manager and then stores said posted-event-indica- 
tion in said posted -event-table and if then said 
event-monitor detects a matching awaiting-event- 
indication in said awaiting-event-table it indicates 
this together with event-data to said workflow-navi- 
gator. 

15. A computer system according to claim 14 

wherein said event -generator is informed, if 
25 said awaited-event-indication is stored in said 
awaited-event-table, on this awaited-event-indica- 
tion. 



35 



said event-management-system encompasses 
the component of an event-monitor administer- 
ing awaited events in at least one awaited- 
event-table and further administering signaled 45 
events in at least one posted- event- table, and 
wherein said event-generator is signal- 
ing the occurrence of said event to said event- 
monitor. 

50 

13. A computer system according to claim 12 

wherein said event-management-system 
encompasses the component of an event-manager 
maintaining information on said event allowing to 
verify correctness of said event if said event is being 55 
signaled. 

14. A computer system according to claim 13 
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1 EVENT_ACTIVITY 'Wait for Response* 

2 ('Event Identification 1 , 'Response Information') 

3 EVENT 'Wait for Customer Response* 

4 END 'Wait for Response' 
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1 EVENT^ACTIVITY 'Wait for Response* 

2 ('Event Identification', 

3 'Response Information* ) 

4 EVENT 'Wait for Customer Response* 

5 NOTIFICATION 

6 AFTER 14 DAYS FORCE FINISH 

7 END 'Wait for Response' 
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1 STRUCTURE 'Event Identification' 

2 'case number* : STRING ; 

3 'customer name* : STRING ; 

4 END 'Case Information* 

5 STRUCTURE 'Response Information* 

6 'response ID* r STRING ; 

7 'type' z STRING ; 

8 END 'Letter Information' 

9 STRUCTURE 'Case Information' 

10 'case number* t STRING ; 

11 * customer name' : STRING ; 

12 'response ID' z STRING ; 
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3 PROGRAM ' Re que s t Customer Info * 
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2 0 TO 'Process Letter' 
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23 TO 'Wait for Response' 

2 4 DATA FROM 'Wait for Response* 

2 5 TO 'Process Fax* 

26 DATA FROM 'Request Customer Info' 

27 TO 'Process Fax* 

28 DATA FROM *Wait for Response* 
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(54) Events as activities in process models of workflow management systems 



(57) The present invention relates to the area of 
workflow management systems (WFMS). WFMS exe- 
cute a multitude of process models consisting of a net- 
work of potentially distributed activities. The current 
invention is dedicated to the implementation of events 
within WFMS. The current invention teaches to imple- 
ment events like any other process activity 
Thus events are implemented as event-activities, a spe- 
cial type of an activity within said WFMS. Such an 
event-activity can manage an event occurring internal or 
external to the WFMS. 

This approach allows to make all features available to 
common activities also accessible to event activities; 
examples are: input-container and/or output-container, 
control-connectors, data-connectors, notification -mech- 
anisms, predicates associated to control connectors 
forming transition conditions and many more. A control 
connector leaving an event activity, which optionally 
may be associated with a logical predicate as outgoing 
transition condition, allows the WFMS to automatically 
activate a target activity if said event activity terminated 
after the event has been ^signaled to said event activity 
and if the outgoing transition condition evaluates to true. 
Similar an incoming control connector, which optionally 
may be associated with a logical predicate as incoming 
transition condition, allows a WFMS to automatically 
activate an event activity if the process activity being the 
source of said incoming control connector terminated 
and if said incoming-transition-condition evaluates to 



true. 

This invention also teaches to extend the navigator of a 
WFMS by an event management system which inter- 
operates with the navigator to deliver above mentioned 
functionality. The event management system encom- 
passes the component of an event monitor administer- 
ing awaited events in a awaited event table and further 
administering signaled events in a posted event table. 
The event management system further encompasses 
the component of an event manager maintaining infor- 
mation on events allowing to verify correctness of an 
event. 
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